Does it make sense to apply this treatment unconditionally if using passthrough shaders? Even if so, I guess we still need a flag when creating the layout, since it's not otherwise known at that point if the layout is going to be used with a passthrough shader. The current BindGroupLayoutFlags doesn't really work for that because it's only used between core and hal.

There should probably be some additional validation along the lines of checking that the binding layouts are consistent with the type of shader, and allowing the "use this interface exactly" mode only when the passthrough shader feature is available.

Unless I'm misunderstanding something, it seems better to have the flag activate the exceptional behavior (i.e. PRESERVE_BINDING_INDICES) rather than deactivate the exceptional behavior?

Can you add a test demonstrating what is fixed? Also, can you say whether this only affects passthrough shaders?

Also, apologies for the absolute silence from us (me).

Can you add a test demonstrating what is fixed? Also, can you say whether this only affects passthrough shaders?

The PR was incomplete, my bad, sorry.

So whenever the origin of a bind group layout is derived, e.g. from the user relying on Naga's reflection. It will use the sequential bindings in Vulkan, since the bindings were never set explicitly by the user, this shouldn't break anything.

So whenever a bind group layout has been set by defining the bindings manually, the vulkan backend will set the descriptors at the same indices as the user declared in their binding.

Why would you want this? When using passthrough shaders, you'd want the user that is supplying SPIRV to expect their bindings to match.

Currently I didn't find any easy way to propagate a flag when the user has used shader passthrough in wgpu, if this is possible, how could that look like?

@dylanblokhuis At the pipeline layout point you don't yet know the exact shader. A single pipeline layout can be used by both a naga-compiled shader and a passthrough shader. I'm not sure exactly how to handle this.

On a semi-related note, I'm gonna be thinking through a precompiled shaders API, would you be ok getting pinged for discussion of that?

Unfortunately I don't think bgl::Origin::Derived works as the control for this. Passthrough shaders will imply explicit BGLs, but not the other way around. And we will want to fundamentally block web content from being able to specify low-level shader interface details, not just stash them behind a flag that it wouldn't normally set.

@dylanblokhuis At the pipeline layout point you don't yet know the exact shader. A single pipeline layout can be used by both a naga-compiled shader and a passthrough shader. I'm not sure exactly how to handle this.

On a semi-related note, I'm gonna be thinking through a precompiled shaders API, would you be ok getting pinged for discussion of that?

Yeah I guess the precompiled shaders API could probably solve this PR by itself, if there's some way for the user to supply their own mappings or heuristic based on backend.

Precompiled shaders are a ways off, so if you need this lets not wait. But my vision for the API is a little bit complicated, which I think is necessary to have powerful passthrough shaders.

I will get to this PR this week, sorry for the long delay.